Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server 2022
Use Azure Pipelines to deploy to Azure Kubernetes Service and Kubernetes clusters offered by other cloud providers. Azure Pipelines has two tasks for working with Kubernetes:
- KubernetesManifest task: bake and deploy manifests to Kubernetes clusters with Helm, Kompose, or Kustomize
- Kubectl task: deploy, configure, and update a Kubernetes cluster in Azure Container Service by running kubectl commands
If you use Azure Kubernetes Service with either task, the Azure Resource Manager service connection type is the best way to connect to a private cluster or a cluster with local accounts disabled.
For added deployment traceability, use a Kubernetes resource in environments along with a Kubernetes task.
To get started with Azure Pipelines and Azure Kubernetes Service, see Build and deploy to Azure Kubernetes Service with Azure Pipelines. To get started with Azure Pipelines, Kubernetes, and the canary deployment strategy, see Use a canary deployment strategy for Kubernetes deployments with Azure Pipelines.
KubernetesManifest task
The KubernetesManifest task checks for object stability before marking a task as successful or failed. The task can also perform artifact substitution, add pipeline traceability-related annotations, simplify creation and referencing of imagePullSecrets, bake manifests, and aid in deployment strategy roll outs.
Note
YAML-based pipeline support triggers on a single Git repository. If you need a trigger for a manifest file stored in another Git repository, or if triggers are needed for Azure Container Registry or Docker Hub, use a classic pipeline instead of a YAML-based pipeline.
You can use the bake action in the Kubernetes manifest task to bake templates into Kubernetes manifest files. The action lets you use tools such as Helm, Kustomize, and Kompose. The bake action of the Kubernetes manifest task shows the transformation between input templates and the final manifest files used in deployments. You can consume baked manifest files downstream (in tasks) as inputs for the deploy action of the Kubernetes manifest task.
Target Kubernetes resources that are part of environments with deployment jobs. Using environments and resource deployments improves pipeline traceability, helping you diagnose deployment issues. You can also deploy to Kubernetes clusters with regular jobs without the same health features.
The following YAML code shows how to bake manifest files from Helm charts
steps:
- task: KubernetesManifest@1
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
helmChart: charts/sample
overrides: 'image.repository:nginx'
- task: KubernetesManifest@1
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: someK8sSC
namespace: default
manifests: $(bake.manifestsBundle)
containers: |
nginx: 1.24.0
Kubectl task
As an alternative to the KubernetesManifest KubernetesManifest task, use the Kubectl task to deploy, configure, and update a Kubernetes cluster in Azure Container Service by running kubectl commands.
This example shows how a service connection refers to the Kubernetes cluster.
- task: Kubernetes@1
displayName: kubectl apply
inputs:
connectionType: Kubernetes Service Connection
kubernetesServiceConnection: Contoso #alias: kubernetesServiceEndpoint
Script task
Use kubectl
with a script task.
This example uses a script to run kubectl
.
- script: |
kubectl apply -f manifest.yml
Kubernetes deployment strategies
The Kubernetes manifest task supports the canary deployment strategy. Use the canary deployment strategy to partially deploy new changes so the new changes coexist with current deployments before a full rollout.
For more information about canary deployments with pipelines, see Use a canary deployment strategy for Kubernetes deployments with Azure Pipelines.
Multicloud Kubernetes deployments
Kubernetes works the same way on all cloud providers. Use Azure Pipelines to deploy to Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), or clusters from other cloud providers.
To set up multicloud deployment, create an environment and add Kubernetes resources associated with namespaces of Kubernetes clusters.
The generic provider approach, based on an existing service account, works with clusters from any cloud provider, including Azure. Using the Azure Kubernetes Service option creates new ServiceAccount and RoleBinding objects. This ensures the RoleBinding object limits the ServiceAccount's operations to the chosen namespace.
When using the generic provider approach, ensure a RoleBinding exists that grants permissions in the edit
ClusterRole
to the desired service account. Grant permissions to the correct service account so Azure Pipelines can use it to create objects in the chosen namespace.
Parallel deployments to multiple clouds
The following example shows how to do parallel deployments to clusters in multiple clouds. In this example, there are deployments to the AKS, GKE, EKS, and OpenShift clusters. These four namespaces are associated with Kubernetes resources under the contoso
environment.
trigger:
- main
jobs:
- deployment:
displayName: Deploy to AKS
pool:
vmImage: ubuntu-latest
environment: contoso.aksnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@1
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: aksnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to GKE
pool:
vmImage: ubuntu-latest
environment: contoso.gkenamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@1
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: gkenamespace
manifests: manifests/*
- deployment:
displayName: Deploy to EKS
pool:
vmImage: ubuntu-latest
environment: contoso.eksnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@1
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: eksnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to OpenShift
pool:
vmImage: ubuntu-latest
environment: contoso.openshiftnamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@1
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: openshiftnamespace
manifests: manifests/*
- deployment:
displayName: Deploy to DigitalOcean
pool:
vmImage: ubuntu-latest
environment: contoso.digitaloceannamespace
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: KubernetesManifest@1
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: serviceConnection #replace with your service connection
namespace: digitaloceannamespace
manifests: manifests/*